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Method for Enhancing the Visibility of Effective Address 
CompuLation in Pipelined Arch iter: tu res 

The present invention relates to the verification of 
sGftv;are applications ported betv/een differing- instruction set 
architectures and to the debugging of softv/are applications 
executed on pipeline architectures. 

As new general -purpose processors and digital signal 
processors (DSP) arc introduced, existing software applications 
are ported from the old generation of processors to the new 
g'?T3eration . When an application is ported, the software 

developer responsible for the port must verify that the 
application executes correctly on the new processor- 
architecture. Generally, this verification consists of 
executing the application on the target processor {or in a 
simulator or emulator) and debugging it when problems are 
detected. This can be a time-consuming process if the 
applications are large. There is no means available to 
automatically verify that the execution of the ported version of 
the application is eopaivalent to the execution of the original 
version whore equivalency means that both versions of. the 
application wrote the same values to memory. 

When an appl ication is ported to a new processor 
architecture, there may not be a one-to-one correspondence 
between the memory addresses in the source program and those of 
the target program. The size of the application may have 
increased or decreased due to instruction set differences or a 
data structure may have been, relocated in memory or merged with 
another data structure to take advantage of special features of 
the target architecture. This disparity in memory addresses 
betv/een the source and the target versions of the application 
complicates the verification process as the contents of the 
mapped address registers in each version will not necessarily be 
the same - 

Moot modern general -purpose microprocessors and digital 
signal processors have a central processing unit (CPU) pipeline 
v/here multiple instructions are in various stages of execution 
at any given time. Instructions may cause effects that mask 
one another at the level of visibility of a debugger, making it 
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v-:i£ficult for a ver if icattion procofjn or a dobiiggor to see th.e 
interim results of an instruction in progress. 

An illustrative emboditnent of the pres:ent invention seelcs 
to provide a software system and method' for auitoinatically 
verifying the correct execution of an application that has been' 
ported from one instruction set architecture (ISA) to another 
ISA. In this method, versions of the application are prepared, 
for the r:ource ISA and the target ISA. These versions are then 
o^<=^cuted on a simulator or emulator for ttie appropriate ISA and 
all changes made in memory during execution are recorded. 
Finally, the results of the two executions are compared to 
determine if they are equivalent and the results of this 
verification are displayed. 

In one embodiment of the present invention, the method is 
enhanced such that during the verification process the source 
and target versions of the application are executed in turn on 
their respective ISA simulator or emulator and a comparison to 
determine ecjuivalency is done each time a change in memory is 
made during execution. 

In another em.foodiment, indirect memory writes are validated 

symbolically during the verification process. The verification 
nrocens treats references to address registers as symbols and 

computes the effective addresses of the analogous references in 

the source and target applications independently when attempting 

to verify that two unreconciled states are e<3uivalent. 

In an embodiment, the verification method is further 

erih.=t^-!ced to increase the visibility of effective address 

computation in pipelined architectures. 

Those and other features of the invention will be apparent 

to those skilled in the art from the following detailed 

description of the invention, taken together with the 

accom.panying drawings in which: 

Figure 1 illustrates the elements of a system embodying the 

prer=!ent invention for automatically verifying the correct 

execution of applications that have been ported from one 

in?:truction set architecture (ISA) to another; 

F.igu-^e 2 is a flow graph of a method used by the system of 

Figure 1 to verify that a source version and a target version of 
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an application ported from one ISA to another exhibit ccfuivalent 
cjtocurion rcoulco ; 

Figure 3, consisting of Figures 3A-3B, presents a flow 
graph of a version of the method of figure 2 for verifying by 
co-execution that a source version and a target version of an 
application ported from one ISA to another exhibit equivalent 
results; 

Figures 4A-4H present a simple example of the operation of 
the verification method of Figure 3; 

Figures 5A-5B present the main graphical display of an 
embodiment of the verification method of Figure 3; 

Figures 6A-6F present the options dialog used to specify 
the parameters for controlling a verification process ..-in an 
embodiment of the verification method of Figure 3; and 

Figure 7 presents a method for enhancing the visibility of 
effective addresses in a pipelined architecture during a 
verification process used by the verification method of Figure 
3. 

Corresponding numerals and symbols in the different figures 
and tables refer to corresponding parts unless otherwise 
indicated . 

h v€ri£ic?.tion tool has been develooe<;J to f^oilitate the 

debugging of ported applications. This tool compares the 

instruction by instruction execution of the -original or ce-ux-oo 
version of the application with the instruction by instruction 
execution of the ported or target version and reports any 
discrepancies at or near the instruction where the two versions 
begin to vary. 

Figure 1 illustrates the elements of a system for 
ciutoTT.atically verifying the correct execution of applications 
that have been ported from one instruction set architecture 
(ISA) to another. General purpose computing system 100 hosts 
two softvj^re development systems as represented by displays 102a 
and 102b ajad verification software as represented by display 
104 . 

In a first embodiment, software development system 102a 
contains simulextion software to support a source ISA, and 
softv/are development system 102b contains sim\ilation software to 
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support a target ISA. The usor prepares two versions of an 
Application to be verified, tHe source version and the target 
version. The source version of the application will execute on 
the source ISA supported by the simulation software in software 
develooment system 102a and the target version will execute on 
the target ISA supported by the simulation software in software 
development system 102b. Verification software 104 causes the 
two versions of the application be executed in the appropriate 
simulation software and verifies that the application has 
equivalent execution behavior on both IGAs. 

m a second embodiment, emulation hardware 105 and 10 6 
connects source hardware 107 and target hardware 10 8 
respectively to general-purpose computer 100. Emulation 
hardware 105 supports the source ISA and emulation hardware 10 6 
supports the target ISA. Emulation hardware 105 is assigned to 
software development system 102a and emulation hardware 106 is 
assigned to software development system 102b. Using the 
appropriate software development system, the user prepares the 
source and target versions of an application to be verified. 
The source version is executed on source hardware 107 under the 
control of emulation hardware 105 and the target version is 
executed on target hardware 108 under the control of emulation 
hardware 106.- Verification software 104 directs each software 
. development system 102 to execute its version of the application 
on the associated emulation hardware. Softv/are development 
system 102 downloads the software application to the assigned 
eiTulation hardware and verification software 104 then directs 
the execution of each version of the application and verifies 
that the application has equivalent execution behavior on both 

In a third embodiment, software development system 102a may 
be connected to emulation hardware 105 supporting one ISA and 
software development system 102b may contain simulation software 
for a different ISA. The user prepares the source and target 
versions of the software application to be verified, one for 
each ISA. Verification software 104 causes the source version 
for the first ISA to be executed by software development system 
102a in emulation mode and the target version for the second ISA 
to be executed by software development .csystem 102b in simulation 



TI-32964 EP 



5 



mode. Verification software 104 then directs the execution of 
each version of the application and verifies that the 
application has equivalent execution behavior on both ISAs . 

The fact that the application is being executed on a 
simulator or an emulator is irrelevant to the operation of the 
present invention. For purposes of simplicity in the remainder 
of this specification, a simulator will be assumed. However, it 
should be noted that a simulator and an emulator may be used, 
interchangeably- For the purposes of the present invention, an 
emulator is: 1) any program, or device with the ability to 
imitate the execution of an instruction set on a processor 
architecture; 2) any device that executes an instruction set as 
it would be executed on its processor architecture (e.g., in- 
circuit emulation); or, 3) any program or device that permits 
user control of the execution of an instruction set on the 
actual processor (on-chip emulation) . 

Figure 2 is a flow graph of a method used by verification 
software 104 to verify that a source version and a target 
version of an application exhibit equivalent execution results. 

In steps 202 and 204, the source and target versions . of the 
application are created. These versions are generally prepared 
(assembled or compiled and linked) using the software 
development tools in the corresponding softv/are development 
system 102. The- source code for the source version* is not. 

changed. The user merely assembles or compiles the source code 
and creates a load module. The user may make some changes to 
the source code to create the target version of the application, 
especially if the two ISAs are not instruction set compatible. 
These changes might include accommodating new instruction 
mnemonics or using features of the target ISA. 

In steps 2 06 and 208, the source and target versions of 
the application are executed in the corresponding ISA simulators 
under the direction of verification software 104. Verification 
software 104 compares the results of the execution of each 
version and determines whether or not the results are 
equivalent. In step 212, verification software 104 displays the 
results of the comparison. 

Figure 3, consisting of Figures 3A-3B, presents a flow 
graph of a version of the method of Figure 2 for verifying by 
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co-execu t i-on that a source verGir>n and a target version of an 
application ported from one ISA to another exhibit equivalent 
results. This flow graph illustrates one way in which steps 
206, 2 08, and 210 of Figure 2 may be interleaved to accomplish 
the verification task. Although this flowgraph illustrates a 
method that begins with the execution of the source version of 
the application, this choice is purely arbitrary. Either 
version may be executed initially. 

In step 3 01, a single instruction of the source version of 
the application is executed in the first ISA simulator. In step 
302, a check is made to determine if the end of the source 
version has been reached. If so, the req:u'ested verification is 
complete and execution continues at step 318. At step 318, a 
check is made to determine if any unreconciled state exists. If 
such a state does exist, failure of the verification is 
indicated at step 319 and the method exits. If no unreconciled 
state exists, success is indicated at step 3 20 and the method 
ends - 

If not, a check is made at step 3 03 to determine if the 
execution of the instruction has created an unreconciled state. 

An unreconciled state is created by a write to an accumulator, 
an address register, or to memory (direct, indirect, or 
absolute) . Execution of the source version continues until 
either the end of the version is reached or an unreconciled 
state is created. When an unreconciled state is found, 

execution of the source version is halted and the target version 
is executed in the second simulator. 

At Fstep 304, a single instruction of the target version of 
the application is executed- If the end of the target version 
is detected in step 305, the reqpaested verification is complete 
and the final portion of the method is executed beginning at 
step 318- If an unreconciled state is detected (step 306), this 
state is compared with the unreconciled states detected in the 
execution of the source version at step 307. If it is not 

equivalent to one of the unreconciled states from the previous 
execution of the source version, execution continiies at step 309 
in sufoflowgraph 1 of Figure B as indicated at step 309a. A 
check is made to determine if tl^e stop on failure option 

(discussed below in reference to Figure 6C) , is active. If it 
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i-r. not accive, the current unrcconcLled state J.g recorded at 
rtep 322 and execution continues at step 3 04. If it is, 

failure of the verification is indicated at step 321 and the 
method ends. 

If an equivalency is found at step 307 by comparing the 
unreconciled state dcstected at step 306 with the unreconciled 
states found in the execution of the source version, the 
equivalent source and target states are marked as reconciled. A 
chock is made at step 3 08 to deteirmine if all unreconciled 
srnrps rpsnltinrj from the evecution of the ^source version have 
been reconciled. If not, execution of the target version 
continues at step 304. If all such states have been reconciled., 
a check is made at step 317 to determine if there are any 
unreconciled state that have been detected and recorded during 
L?iis execution of the target version. If there are, execution 
of the source version is resizmed at step 310. Otherwise,, 
execution of the source version resumes at step 301. 

At Step 310, a single instruction of the source version of 
the application is executed. If the end of the source version 
is detected in step 311, the requested verification is complete 
and the final portion of the method is ex<=icuted beginning at 
rrf-f^ip 318. If an unreconciled state is detected (step 312)', this 
^tate is cojppared at step 313 with the unreconciled states (if 
any) detected in the execution of the target version. If it is 
not equivalent to one of the unreconciled states from the 
previous execution of the target version, execution continues at 
step 3 09 in subflowgraph 1 of Figure B as indicated at step 
309b. A check is made to determine if the stop on failure 
option (discnnsed below in reference to Figure 6C) is active. 
If it is not active, the current unreconciled state is recorded 
ac .step 322 and execution continues at step 310. If it is, 

failure of the verification is ind.icated at step 321 and the 
method ends . 

If an equivalency is found at step 313 by comparing the 
unreconciled state detected at step 312 with the unreconciled 
states found in the execution of the target version, the 
equivalent source and target states are marked as reconciled. A 
check is made at step 314 to determine if all unreconciled 
states resulting from the execution of the target version have 
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b(ru7ra reoonoiled. If not, execution of tho source version 
continues at step 310. If all such states have been reconciled, 
a check is made at step 316 to determine if there are any 
unreconciled states that have been detected and recorded during 
this execution of the source version. If there are, execution 
of the target version is resumed at step 304. Otherwise, 
execution of the source version resumes at step 301. 

Figures 4A-4H present a simple example of the operation of 
the verification method of Figure 3. Source column 403 contains 
a short sequence of assembly language instructions for the 
source ISA. Target column 404 contains another short sequence 
of assembly language instructions for the target ISA. This 
latter sequence, when executed, yields equivalent results to 
that of the sequence in source coliomn 403 . The operation of 
each instruction is explained in Table 1. Source state column 
405 and target state column 406 contain any unreconciled state 
that occurs as the associated instruction sequence is executed. 

Arrows 401 and 402 indicate the execution progress of the 
source instruction sequence and the target instruction sequence, 
respectively. Table 2 contains the mapping of the registers 
between the source ISA and the target ISA. This mapping 

determines how each register in the source ISA is to be compared 
to the corresponding register in the target ISA during the 
verification process. 
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Inf3r.ruct ion 


Explanation 


STM datal. AR3 


Store the address of datal in 
address register 3 . 


LD #1, A 


Load a register (A) v/ith an 
immediate value (1) 


NOP 


No operation 


STL A, *AR3-t- 


Store the low bits of the 
accumulator (A) to memory at the 
address in address register 3 
and autoincrement the address 


MOV datal, AR3 


Store the address of datal in 
address register 3 


MOV #1, AGO 


Move an immediate value (1) to 
the accumulator (AGO) 


MOV ACO«#0, 
AR3 + 


Move the low bits of the 
accumulator (AGO) to memory at 
the address in address register 
3 and autoincrement the address 



Table 1 



Source 
Register 


Target 
Register 


A 


AGO 


B 


ACl 


ARl 


XARl 


AR2 


XAR2 


AR3 


XAR3 


AR4 


XAR4 


AR5 


XAR5 


AR6 


XAR6 


AR7 


XAR7 



Table 2 



Figure AA illustrates the initial state. before the 
verification bogins. Arrows 401 and 402 arc pointing to the 
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first instruction in their associated instruction sequences arxd 
state columns 405 and 406 are empty. In Figure 4B, the first 
instruction in source column 403 has been executed and arrow 401 
is now pointing to the second instruction. The execution of . the 
first instruction caused the address of the variable datal to be 
written into register ARB thus creating an unreconciled state - 
The existence of this unreconciled state is recorded in source 

state column 405. 

Because there is now an unreconciled state, execution of 
the source instruction sequence is stopped and the target 
instruction sequence is executed in an attempt to create an 
equivalent state. In Figure 4C, the first instruction in target 
column 404 has been executed and arrow 402 is pointed to th.e 
subsequent instruction. The execution of the first target 
instruction caused the address of the variable datal to be 
written into register ARB thus creating an unreconciled state. 
The existence of tbis unreconciled state is recorded in target 
state column 406. Although the value written into ARB by tbe 
target sequence is different than that written into ARB by the 
source sequence, these states are possibly equivalent as long as 
ARB is used as an address register. However, the states are not 
yet reconciled. Doth instruction sequences must be executed 
further to ascertain whether a reconciliation occurs. 

Leaving the ccnt^iits of dsLatLe colauiiifS 405 ctiid 40G uxivhciiivi«=sd 
an a fuM eanivnlency has not been roiirun {"hp pxprutinn nf thp 

fsFTnnd i ^^=lt-T-ur^^ on r»f the sourrp .spqiienre hns been exprnted and 
arrow 401 ia pointing to tho oubocqucnt NOD inotruotion. . TKa 
execution of this instruction has created another unreconciled 
state as indicated in source state column 405 because a constant 
1- -iiaa been wiiLLeii Lo the dccumulaLur A. 

RetUT-ning to the target instruction sequence, the next 
in.struction, in its sequence is executed as shown in Figure 4E . 
jSirrow 402 has been moved to the subsequent NOP instruction and a 
constant 1 has been written to accunnilator AGO. This new 

uiUj-rbCOiiv^llea cLciLe li= a.ci^<^J.a<=a ill L<:ii.y«L i,LcaL<:i ^wluiuui 40G. At> 

Table 2 above indicaten, acjflumulfif.ftr A .in t.YiC ncAivcn TTA -in f.rt 

be compared to accumulator AGO in the target architecture for 
verification purposes. Both have had the same value written to 
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them, so the cource state and the target state are equivalent 
and may be reconciled. These states may now be removed from 
state columns 405 and 406 as is sho\^7n in Figure 4F , 

Returning to the source instruction sequence, thie 
instructions are executed until a new unreconciled state is 
created by the execution of the STL instruction. As Figure 4F 
illustrates, arrow 401 is now pointing to the NOP instruction 
following the STL instruction. This instruction has caused the 
contents of accumulator A to be written to the memory address in 
register ARB. ' This new unreconciled state is reflected in state 
column 403 • 

Returning to the target instruction sequence, tbe 
instructions are executed until a nev/ unreconciled state is 
created by the execution of the MOV instruction. As Figure 4G 
illustrates, arrow 403 is now pointing to the NOP instruction 
following the final MOV instruction in the target instruction 
sequence. This last MOV instruction has caused the contents of 
accumulator AGO to be written to the memory address in register 
AR3. This new unreconciled state is reflected in state column 
405, V • 

At this point, both the source and the target have used 
corresponding registers (see Table 2) as address registers and 
have written the same value to memory based on the contents of 
those registers- The execution states of the source and the 
L'?.rget are equivalent and the unreconciled states dealing with 
AR3 may now bo removed from state columns 405 and 406. Figure 
4H reflects that the verification up to this point is successful 
ciricl all unreconciled states have been reconciled. 

Figures 5A-5B representative illustrations of a main 
graphical di-splay of an embodiment of the present invention. 
Figure 5A exemplifies the contents of this display when the 
verification program is started and Figure 5B exemplifies the 
contents of this display when a verification is in progress. 
This display is comprised of menu bar 500, tool bar 502, message 
view 504, verification state view 506, and status bar 508. Menu 
bar 50C is used by the user to input all commands to the 
verification tool. The options available for each menu item are 
presented in Table 3 below. 
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Submenu 



File 



View 



Tar-get 



Nev/ (ctrl-N) 



Open(ctrl-O) 



Save (ctrl-S) 



Action 



Start a new verification document, 
closing- the current document if| 
one exists. 



Open an 
document . 



existing verification] 



Save the 
document 



current 



verification] 



Save As 



iSave the current verification) 
document as a different name 



Close 



Iclose the current verification! 

jdocument. Prompt the user! 

joffering to save if the documentj 
las been modified. 



f ilel 
f ile4> 



Exit 



lUp to 4 of the most recent lyj 
jopened files* Selecting one of] 
Ithese will open that file. 
(Exit the program 



Status bar ^Show/hide the status bar 



Toolbar 



Show/hide the toolbar 



Code Composer Ishow/hide 

system 



s o f t wa r e de ve 1 opmen t ] 



Options . . 



jshow the options dialog 



Run 

Verification 



lun a verification session until aj 
problem is found or the stop} 
laddress is reached 



Step 

Verification 



jStep one software 
[(whichever needs to 
luntil the state 
rer i f i c a t. i on changes 



development! 
be stepped): 
of the| 



Stop 
Verification 



verification that is] 



Step Source 



Stop a 
jrunning 

Step^""the program in 
software development 
instruct Ion 



the source 
system one 
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Step Target 


Step Che program in the target^ 

s*-^ i- wd I. 'Bf V V ^ i lyiiiis L, jy j», L» ^lll OXICJ; 

i nntriirtt -i on ■ 


Help 


Topics 


Bring up help, showing the tabid 
of contents 


About 


Show the About dialog. 



Table 3 

Toolbar 502 provides the user v/ith icons to use as 
shortcuts to commonly used functions such as those used to 
control the progress of the verification. Status bar 508 

displays messages indicating the state of the verification 
process. As the source or target program is stepped, the action 
taken is displayed on the right side of status bar 508. Also, a 
snort description of each menu item or toolbar button 
highlighted appears in status bar 508. 

Verification state view 506 displays the list of 'all 
unreconciled state changes that have occurred in the source and 
target programs. It displays the register or memory address 
that is affected and the contents of that register or memory 
address. Icons in column 510 indicate the status of the 

reconciliation attempts for each associated pair of unreconciled 
states. Table 4 defines the icons that may be present in column 
510. An example of the contents of verification state view 50 6 
during the execution of a verification is shown in figure 5B. 
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icon ] 


^explanation 


I 


icon indicates that this item has not yet 
been determined to match or not match. 


] 

Check 


h. green check indicates that this item has 
[natched and will be cleared from the display 
after a number of steps indicated in the 
Display dialog - 


■X 


A red X indicates that this item has been 
written by both the source and the target, 
but with different values. This indicates 
an incompatibility that should be examined 
by the user. 




A purple exclamation indicates that a 
warning has been noted on this item because 
the state of the two CPUs was not consistent 
during the execution of this item. This 
item should be examined by the user. 


Clock 


A clock indicates that this item rs over 
aged, that is, significant time has elapsed 
(time limit specified by user) since one 
version wrote to this item and the other 
version has yet to write to the item. The 
verification process will continue to track 
the item looking for a match, but this item 
will no longer influence ex:ecution of the 
verification algorithm. 



Table 4 



Message view 504 displays a scrollable list of messages 
from the verification program. These messages keep the user 
informed of the state of the verification process. The user may 
control what level of messages are sent to this window 
(diagnostics, verbose information, short information, error 
messages) through the options dialog described in the discussion 
of Figijires 6A-6F below and may log the merrf^ages to a file. 
Messages may be triggered by starting, stopping, or stepping a 
verification, the detection of a stop address in the source 
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program, the removal of an addrosG regi.oter mismatch due to a 
successful write-through of the address register with the same 
values, etc. An example of the contents of message view 504 
during the execution of a verification is shown in figure 5B . 

Figures 6A-6F are representative of an options dialog used 
to specify the parameters for controlling a verification. Each, 
of 6A-6F represents a screen displayed in response to the 
selection of one of the tabs 630-635, When the user selects 
File/New (see Table 3) from toolbar 500, the options dialog 
screen in figure 6A is displayed. {This dialog is also 

displayed when the user selects the View/Options from toolbar 
500 to modify a previously created verification document or when 
file tab 630 is selected.) Files display 600, which is the 
default initial screen when the options dialog is displayed, 
allows the user to specify the source and target programs to be 
loaded into the source and target simulators. ' 

A verification document is a file that contains all the 
parameters for a verification session. These parameters are 
defined by the user using the options dialog shown in Figure 6A- 
The parameters are comprised of the file names of the source 
and target versions of the application, a list of ON, OFF, and 
STOP trigger addresses for both the source and target versions, 
the maximum number of verification steps to be executed before 
an unmatched item is considered a difference, etc. 

Triggers display 602, displayed by selection trigger tab 
631 and shown in Figure 6B, allows the user to specify addresses 
in the source and target programs v^here verification is turned 
en, turned off, or stopped, ON verification points are 

addresses where the validation process should start (or restart) 
reconciling the actions of the source and target programs, OFF 
veri f i cat: i on points are addresses where the verification should 
stop reconciliation and simply run the program until the next ON 
or STOP point, STOP verification points are places where the' 
verification process should halt, Addre-sses 604 and 606 may be. 
entered in decimal or hexadecimal numeric format or may be an 
actual symbol in the program. List displays 608 and 610 display 
the addresses and typos of all triggers that have been specified 
for the source and target programs, respectively. 
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Verification display 612, cliGplayed by selecting 
verification tab 632 and shown in Figure 6C, allows the user to 
set some generic options related to the verification process. 
These options include stop options 614 and verification type 
options 616. Stop options 614 allows the user to optionally 
require the verification process to halt when a difference 
between the source and target programs is detected- The meaning 
of a "difference" depends on the selection made in address 
registers options 619 (see Figure 6D) . If this option is not 
selected, the verification process will execute and simply log 
differences to message view 504 and optionally to a message log 
file- Verification type options 616 allow the user to specify 
the iSAs of the source and target programs. 

Registers display 618, displayed by selecting registers tab 
63 3 and shown in Figure 6D, allows the user to specify the 
strictness of the register comparison to be used during the 
verification process. If the "Track register contents" of 
Address Registers 619 is selected, the contents of the address 
registers in the source program are compared with the contents 
of their counterparts in the target program. (See Table 2,) 
This option should only be used if the two programs have been 
linked at the same memory location. It will provide a stricter 
comparison between the two programs. If the two programs have 
not been. linked at the same memory location, the "Do not track..." 
option of Address Registers 619 should be used. With this 
option, the actual contents of the address registers will not be 
tracked but writes to memory through those registers will be 
tracked . 

Display display 620, displayed by selecting display tab 634 
and shown in Figure 6E, allows the user to specify the level of 
detail to be shown in verification state view 506 and message 
view 504. In State Display 622, the user may specify the number 
of steps to show matched (reconciled) items before removing them 
from verification state view 506. In Messages 624, the user may 
specify the types of messages to be displayed in message view 
504 and request to have the messages written to a user-specified 
log file. The message types are defined in Table 5. 
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Errors 



A recoverable error due to an 
unexpected input to the verification 
tool. The tool atteir.pts to continue 
the verification, but the user should 
examine the source of the error. 
This type of error may occur if the 
simulator detects invalid 

instructions . 



Warnings 



The verification process has found an 
inconsistency in the execution the 
source and target programs . The 
exact nature of the inconsistency is 
listed in verification state view 
506 . 



Information 



Informational messages for the user 
about the status of the verification 
(e.g. ON, OFF, STOP triggers hit). 
Running, Stopped, Stepped. 



Verbose 
Info rma t i on 



More detailed information, 

particularly suited for logging to 
the log file. The text from Comments 
display 624 is printed as a verbose 
message when the .session is started. 



Diagnostics 



Diagnostic messages meant- to aid in 
the reporting of bugs in the 
verification tool. This level of 
messages may produce a great deal of 
text, including the details of each 
step of the verification process • 



Table 5 



Comments display 62 6, displayed by selecting comments tab 
63 5 and shown in Figure 6F, allows the user to enter a text 
comment for the associated verification document. This is 
useful for describing the purpose of the document. These 
comments are displayed in message view 504 when the document is 
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opened iC the verbose information option is solcctcd in Messages 
624. 

When an application is ported to ci different XSA, there maY 
not be a one-to-one correspondence betv/een the memory addresses 
in the source program and those of the target program. The size 
of the application may have increased or decreased due to XSA 
differences or a data structure may have been relocated in 
memory or merged with another data structure to take advantage 
of special features in the target IGA, This disparity in memory 
addresses between the source and the target versions of the 
application complicates the verification process as the contents 
of the mapped address registers in each, version will not 
necessarily be the same. 

Indirect memory writes are validated symbolically during 
the verification process. Indirect writes to memory through 
address register expressions are verified by determining that 
the values wr-itten to memory locations computed* by the address 
register expressions in the source and target versions are 
equivalent. The verification process treats references to 

address registers symbolically and computes the effective 
addre£?ses of the analogous references in the source and target 
application3 independently when attempting to verify that two 
^-jnreronci 1 ed states are equivalent. 

The example sequence of assembly language code in Figures 
4A-4Ii illustrates this embodiment. The memory location of datal 
is different in the source and target code, so that the contents 
of AR3 after the first instruction in oach code sequence is 
different as sho^ATi in source state 405 and target state 406 in 
Figure 4C . When the instruction STL A, *AR3+ is executed, the 
contents of register A are written to the memory address stored 
in register ARB as shovm in source state 405 of Figure 4F. At 
this point, rather than treating the unreconciled state created 
by this change to memory as a write to the m.emory address 0x800, 
::ho iir r r^*'onc : 1 Gd state is remembered as being a v/rite to the 
r.:emory adc.recs represented by the symbol *AR3 . Mote that if the 
UP roconc I'j .^d state is viewed as being a change in memory at 
c:;.ddress 0x800, no equivalent state v/ould ever be detected on the 
target processor because of the different memory addresses of 
the symbol datal. When the instruction MOV ACO«#0, AR3+ is 
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ryoont:ed on the target TFjA, the cont-.ents of register ACO is 
v/ritton to the memory address storod in register AR3 as shown in 
target state 406 of Figure 4G- This unreconciled state is 
viewed as being a write to the memory address represented by th.e 
symbol *XAR3 . When checking to see if this new unreconciled 
state is equivalent to the unreconciled state created during thte 
execution of the code sequence on the source ISA, the validation 
process recognizes that the source unreconciled state and the 
target unreconciled state are both v/rites to the same symbol. 
(The registers AR3 and XAR3 are equivalent for verification 
purposes as shown in Table 2,) Therefore, if the same value 
has been written to memory at the respective addresses 
roprc^snnted by this symbol in the source and target executions, 
the two unreconciled states are ecpaivalent and may be 
reconciled. It is important to note that any register 

a:<pref?;sion involving symbols and constants, such as XAR3 + 5, 
not just simple register expressions, will be handled simi!larly. 

Figure 7 presents a method for enhancing the visibili'ty of 
effective addresses in a pipelined architecture duiring a 
verification process. Note: An effective address is the address 
at which a memory operation occurred. Through the use ^of this 
method, a verification process or debugger can infer the 
effective address of . many instructions in a pipeline 
architecture where that" effective address' V70u Id otherwise be 
invisible due to the behavior of the pipeline. 

Most modern general -purpose microprocessors and digital 
r^icjral proces.9ors have a central proceoairg unit (CPU) pipeline 
vvhere multiple in.s truct ions are in various stages of execution 
at any giv^^n time. Instructions move through the pipeline like 
products through an assembly line. At each phase of the 
pipeline, c^ach instruction performs an action specific to that 
phase. For example, an ADD instruction will read both operands 
during the Read phase and perform the addition during a later 
Execute phase. 

When a pipelined processor is halted, often the pipeline is 
left "full" of partially executed instructions. The state of 
execution of the application includes whatever effects have 
cilready taken place from these partially executed instructions. 
Instructions may cause effects that mask one another, making it 
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i1-:fficulfc to see the interim re--...! t-3 of an jnnhruction In 
progress. One particular problem is determining Che effective 
^-^rjdro^s of a memory operation v/hen that address is calculated, 
used, and altered while the inr.trxiction causing the memoiry 
operation is still in the pipeline. By the time such an 
instruction is completely executed, the effective address of the 
actual memory operation is no longer available. 

For example, assume that the CPU instruction pipeline has 
four phases: decode, access, read, and execute. Instructions 
enter the pipeline in the decode phase and move through the 
access, read, and execute phases in sequence. Table 6 

illustrates what occurs in each phase of the pipeline when a 
simple memory write is caused by the execution of a store 
instruction such as ST A, *ARl i- . This instruction causes the 
contents of register A to be written into memory at the 
effective address contained in register ARl. In addition, ARl 
will be incremented to the next memory address. 



Pipeline 


Effect 


Phase 




Execute 


Memory at th.e effective address is 
written 


Read 


Value of A is read 


Access 


Effective address for this operation 
is set, and ARl is increinented 


Decode 


"instruction is decoded (i.e. 
recognized) 



Table 6 



As Table 6 illustrates, by the time the instruction is executed, 
the register ARl no longer contains the address where the actual 
writte occurred, the effective address of the instruction. This 
effective address is almost, never available to emulators or 
debuggers and discerning the actual effective address is 
difficult at times. 

The iTiethod presented in Figure 7 works within the following 
conntraint-.s wVn ch are common to most pipelined architectures: 1) 
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.-^iLl inst:ruct ions enter the pipclini^ at one pa.vticular phase 
(often called decode); 2) all instructions travel through the 
en^.ire pipeline even though they may not perform meaningful work 
at each phase of the pipeline; and, 3) the number of clock 
cycles that a given instruction will spend in each phase of the 
pipeline can be determined a priori. 

At step 700, a determination is made as to wh.at 
instructions are currently in the pipeline. There are a number 
of ways to accomplish this determination including: 1) 
executing the software in single-step mode and recording eacb 
instruction as it enters the pipeline; or, 2) utilizing an 
emulator or simulator that can report which instruction is in 
each phase of the pipeline. Such features are available in some 
modern emulators and simulators. 

Once this determination is made, the current effective 
address for any relevant instruction in the pipeli*ne * is 
ascertainable in most instances. Note: In rare cases, lit' may 
rot be possible to determine the current effective address ^sucli 
as when an address register is used and then reloaded ' from 
memory in a subsequent instruction. First, in step 702 > the 
effective address delay of the instruction is calculated/'' This 
effective address delay is the number of CPU clock cycles from 
the point where the instruction enters the pipeline at the 
decode phase to the point where the effective address that will 
bo used for the instruction is fully computed. The effective 
address delay is then reduced by the number of clock cycles that 
have occurred since the instruction entered the pipeline. The 
resulting m:imber is used in subsequent steps of the method to 
dotermine if a current effective address is available, is not 
applicable as the instruction has not reached a phase where the 
effective address is calculated, or must be "inferred" because 
the effective address has been masked by the execution of 
sub*5equent instructions in the pipeline- 

In strep 704, if the current effective address delay of the 
in.-:: true t ion is 0, the effective address for the memory operation 
i ?3 available and is reported at step 718. The method then 
proceeds to the next instruction in the pipeline, if any, via 
step 720. II the current effective address delay is found not 
to be less than 0 at step 706, no further action for the 
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instruction under consideration is required as the instruction 
has not yet reached a point where a memory operation has 
occurred. The method proceeds to the next instruction in the 
pipeline, if any, via step 720. 

If, at step 706, the current effective address delay is 
negative, the effective address of the xneTtiory operation has 
potentially been compromised. At step 708, a check is made to 
determine if any of the subsequent instructions in the pipeline 
have modified any of the factors that are involved in the 
effective address calculation of the instruction under 
consideration. If not, the current effective address may be 
reported and the method proceeds to the next instruction in the 
pipeline, if any, via step 720. If the subserjtient instructions 
have modified one or more of the factors involved in the 
effective address calculation, a check is made at step 710 to 
determine if these modifications are reversible (i.e., the 
modifications can be applied in reverse order to the current 
effective address to determine the actual effective address of 
the instruction) . If the modifications are reversible, at step 
712, the actual effective address is determined and reported. 
The' method proceeds to the next instruction in the pipeline, if 
any, at step 720. If, at step 710, a determination is made that 
the' modifications are not reversible, an indication that there 
is no. effective .address available for the current in.struction is 
reported and the method proceeds to the next instruction in the 
pipeline, if any, at step 720. 

The verification process includes a method for enhancing 
the visibility of effective address computation in pipelined 
architectures when the application to be verified is executed on 
a CPU with a pipelined architecture (source and/or target). The 
application program is executed in single-step mode to detect 
unreconciled states as they occur. At each execution step, the 
verification . process calculates the current effective address 
delay for each instruction in the pipeline and reports the 
current effective address (if possible) as illustrated in Figure 
7. The verification process knows what instructions are in the 
pipeline and their current pipeline phase because it remembers 
each instruction as it enters the pipeline and knows how many 
clock cycles are required for each relevant phase of each 
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.nntr. ruction . 

For example, consider the e>recijtzion of the code sec[uence in 
?able 7 . 



(line 1) NOP 

(line 2) 

(line 3> STM #100, ARI 

(line 4) ST A, *AR1+ 

(line 5) ST A, *AR1+ 

(line 6) NOP 

(line 7) 



ARI 

memory (100) 
memozry (101) = 



NOP 
100; 
= A 
A 

NOP 



Table 7 



Table 8 contains a brief explanation of the operation of each 
instruction of the code secpaence in Table 7. . > 



Ins truction 


Exp lana t ion 


WOP 


No operation 


STM • #100/ 
ARI 


Store iinmediate value (100) into 
address register 1 


ST A, *AR1+ 


Store the contents of recjister A 
into the memory address contained 
in address register 1 and 
autoincrement the address 



Table 8 
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T'-Me 9 shov7 the contents of the pipeline when the instruction 
on. line 4 of Table 7 enters the decode phase. 



Pipeline 
Phase 


Instruction 


Execute 


(line 2) NOP 


Read 


(line 3) STM #100, 

ARl 


Access 


(empty) 


Decode 


(line 4) ST A, 
•*AR1+ 



Table 9 

The effective address delay for this instruction is two because 
its effective address will be set in two clock cycles. The 
pipeline contents after the next single step are shown in Table 
10 . 



Pipeline 
Phase 


Instruction 


Execute 


(line 3) STM #100, 
ARl 


Read ■ ■ 


(empty) 


Access 


(line 4) ST A, 
*AR1 + 


Decode 


(line 5) ST A, 
*AR1 + 



Table 10 



A- this point, the effect address delay of the instruction on 
line 4 is one because its effective ^lddress will be set in one 
ryr-lR. The instruction on line 5 is a tvjo-cycle instruction so, 
on the next single step, the pipeline will advance two phases. 
The resulting contents of the pipeline are shoivn in Table 11. 
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Pipeline 
Phase 


Instruction 


Execute 


(line 4) ST A, 
*AR1+ 


Read 


(line 5) ST A, 
*AR1+ 


Access 


< empty) 


Decode 


(line 6) NOP 



Table 11 

The effective address delay for the instruction on line 4 is now 
a negative one because of the tv/o-cycle instruction that 
follov/ed it in the pipeline. The addr^ess in ARl has been 
incremented twice and the effective address of the instruction 
is not visible to the verification process. Because the 
instruction on line 5 has not changed the contents of ARlt {other 
than the autoincrement ) , the effective address for the 
instruction on line 4 can be "reverse-engineered" by simple 
STibtraction . In the general case, this reverse engineering may 
be more difficult if bit-reversed addressing or circular 
addre<=5sing modes are used but is it usually a tractable p±-oblem. 

In the rare case where it is not possible to reverse the effect 
of a later instruction^ such as reloading- ARl from memory rather 
than a simple autoincrement, the verification process warns the 
user that the verification might be inaccurate. 

Thus, a system and methods have been described for 
verifying that a ported version of a software application has 
execution behavior ecfuivalent to the original version- The 
present invention provides a significant advantage over the 
prior art. Verification by comparing the execution behavior of 
the source and target versions of an application provides 
thorough and detailed validation that the target version is 
executing correctly. Because the verification process examines 
each instruction, the user can know exactly where the two 
versions of the application differ, not just that they differ. 
And, by running each version of the application in a simulator 
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cr emulator under ttie control of a full software developmeixt 
system, v;hen a discrepancy is found diir iria the verification 
process, the debxigger in each software dovelopin'?nt systeirt can t>e 
activated at tbe point of the discrepancy, thus facilitating the 
debug process . 

The present invention is discussed in conjunction with 
softv/are verification and debugging. However, it has 

applications that extend beyond softv/are. Dfhile the invention 
has been described with reference to illustrative embodiments, 
this description should not be construed in a limiting sense. 
Various other embodiments of the invention will be apparent to 
persons skilled in the art upon reference to this description . 

For example, the verification method may be applied to any 
automated process that produces inte-rxrediate states during 
execution and is amenable to emulation or simulation. 

As used herein, the term "debug" is not intended to be 
limiting. DebiAg operations refer to any of the sort of tasks 
performed during development of softv/are and/or hardware, 
including hardware emulation. 
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What is Claimed is: 

1. A method for determining in software the effective 
address of instructions in a program executed on a pipelined 
architecture where there is no ortornal visibility into the 
pipeline, the method comprising: 

executing a first program; 

determining that a first instruction is in the pipeline; 
calculating the current effective address delay of the 

instruction in the pipelined- 
finding that a valid effective address for the instruction is 

avail^tbli b&s4i£l th* i=uri;AiiLL &££<S:Ctiv^ aJLcIaJ^^s-, dela^ of Lh*:^ 

instruction; 

computing the effective address of the instruction if a valid 
effective address is not avai 1 a'hJ and 

reporting the effective address of the instruction. 

2. The method of Claim 1 wherein: 

the step of calculating comprises subtracting the number of 
clock cycles that have occurred since the instruction entered the 
pipeline from the number of clock cycles required to compute the 
effective address of the instruction; 

the step of finding comprises determining that the current 
effective address delay is 0; and 

the step of computing is executed if the current effective 
address delay is less than 0. 
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Met:lvv;3 for Enhancing the Vifv Ibi 1 i of Effective Address 
■ Computation in Pipelined Architectures 

Abstract 

The invention relates to a method to increase the 
visibility of effective address computacion in pipelined 
architectures. In this method, the current effective address 
delay of each instruction in the pipeline is calculated (702) • 
The current effective address delay is used to determine if a 
valid effective address is available for each instruction (705, 
706) . If a valid effective address for an instruction is not 
available (706), it is computed if possible (710, 712). 
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